home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 17516 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  1.9 KB
  1. Path: EU.net!sun4nl!ittpub!ittpub!nntp
  2. Newsgroups: comp.lang.c++
  3. Subject: Re: Why don't you use garbage collection
  4. Message-ID: <1996Apr16.110526.1846@ittpub>
  5. From: wil@ittpub.nl (Wil Evers)
  6. Date: 16 Apr 96 11:05:26 WET
  7. References: <AD94A731966836BF@dialup97-6-14.swipnet.se>
  8. Distribution: world
  9. Nntp-Posting-Host: lintilla
  10.  
  11. In article <AD94A731966836BF@dialup97-6-14.swipnet.se> lars.farm@nts.mh.se  
  12. (Lars Farm) writes:
  13. > In article <AUSTERN.96Apr12095652@isolde.mti.sgi.com>,
  14. > austern@isolde.mti.sgi.com (Matt Austern) wrote:
  15. > 
  16. > >In C++ we're used to the idea that heap-allocated and stack-allocated
  17. > >objects have different rules.  It's not so radical to introduce
  18. > >garbage-collected objects as a third category.
  19. > 
  20. > My sentiments exactly.
  21.  
  22. OK, let's get serious about this:
  23.  
  24. 1. Don't we think C++ is complex enough as it is?  In my experience, the  
  25. main obstacle to get people to use C++ is its steep learning curve, and  
  26. adding yet a third category of objects wouldn't make things any easier. 
  27.  
  28. 2. Will the destructors of garbage collected objects be called?
  29.  
  30. 3. If the answer to (2) is NO: how do we make sure we don't get resource  
  31. leaks for non-memory resources? 
  32. To elaborate: IMHO, the type of resources used by a particular class is an  
  33. implementation detail its users should not have to know or worry about,  
  34. and implementers should be able to change that without affecting the  
  35. users. 
  36. But even if we drop this constraint, derived classes should be able to use  
  37. additional resource types without changing the `garbage collectability' of  
  38. objects accessed through the base class interface.
  39.  
  40. 4. If the answer to (2) is YES: when will these destructors be called?   
  41. What can we assume about the state of the program when the destructor  
  42. runs?  How do we guarantee a shortage of non-memory resources is detected  
  43. by the garbage collector before we get to the point where the program  
  44. can't continue?
  45.  
  46. - Wil
  47.